home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16126 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.9 KB

  1. Path: news.crd.ge.com!rebecca!rpi!not-for-mail
  2. From: ranjit@fwasted.zk3.dec.com (Ranjit Mathews USG)
  3. Newsgroups: comp.lang.c++,comp.lang.c++.moderated,comp.object
  4. Subject: Re: C++ objects in shared memory
  5. Date: 9 Apr 1996 08:49:33 -0000
  6. Organization: Digital Equipment Corporation
  7. Sender: cppmods@netlab.cs.rpi.edu
  8. Approved: devitto@ferndown.ate.slb.com
  9. Message-ID: <4kd8at$mbr@netlab.cs.rpi.edu>
  10. References: <4k1ooa$lru@netlab.cs.rpi.edu>
  11. NNTP-Posting-Host: netlab.cs.rpi.edu
  12. X-Original-Date: 9 Apr 1996 04:25:11 GMT
  13.  
  14. I think I've read that Sun C++ offers the capability for compiling libraries
  15. in such a way that library functions appear at the same virtual address in each
  16. of several processes into which the libraries are linked. I've read a posting
  17. claiming this, so I'm surprised to hear you say that this cannot be done on
  18. Solaris. But then, you might be right and the other posting might've been wrong.
  19.  
  20. You could try to use RTTI to identify the type of the object and use the
  21. object's copy constructor to create another object of the same type. You could
  22. use a letter-envelope idiom to avoid copying data members (you copy only the
  23. reference to the data in shared memory). I haven't used RTTI, so readers may
  24. feel free to correct me if RTTI can't be used in this manner.
  25.  
  26. Alternately, you could write a loader program that has the class library built
  27. into it. Suppose you want programs A & B to map a shared memory segment at a
  28. given address and want B to use objects constructed by A in shared memory.
  29. Let's call the loader L. Create executables A' & B' linked with the linker
  30. options necessary to ignore unresolved references to the shared library.
  31. Let the loader fork itself twice. Each of the child processes has the library
  32. functions at the same virtual addresses. Now, dynamically load A' into the
  33. first child, using sbrk to allocate memory for loading A' and ld to
  34. incrementally link A' against the library contained in child 1. Do likewise for
  35. B'. Now you have two processes A & B, both of which have class library
  36. functions mapped to the same virtual addresses.
  37.  
  38. Refer to Jim Coplien's book for coding examples to the techniques described
  39. above.
  40.  
  41. In article <4k1ooa$lru@netlab.cs.rpi.edu>, Tony Confrey <ac11@gte.com> writes:
  42. |> Apologies if you've already seen this, I'm unclear if my newsreader
  43. |> is set up correctly.
  44. |> 
  45. |> I am trying to store instances of C++ objects in shared memory so 
  46. |> that their function and data members can be accessed by multiple
  47. |> processes running on the same unix box.
  48. |> 
  49. |> Storing the instance in shared memory is no problem - I've been using
  50. |> placement new with a previously allocated block of shared memory that
  51. |> all processes connect to. Calling member functions, in particular 
  52. |> virtual member functions, is more difficult.
  53. |> 
  54. |> I'm finding (actually more like deducing) the following: If process 
  55. |> A creates an instance then the vtbl points to function addresses in
  56. |> process A's address space. Calling non virtual functions or 
  57. |> accessing data members from another process, B, works fine. 
  58. |> However calling virtual functions from B segv's because its 
  59. |> trying to call outside its address space. 
  60. |> 
  61. |> For a while it looked like linking the class library as a shared library
  62. |> would work - in fact it does under aix - because the functions end up in 
  63. |> the same place in memory. However under solaris the address spaces are
  64. |> mapped differently.
  65. |> 
  66. |> Any suggestion would be appreciated. Can this be done? Is there some
  67. |> other approach I should take? I find it hard to believe that no 
  68. |> one has ever tried such a thing.
  69. |> 
  70. |> Thanks
  71. |> 
  72. |> Tony
  73.  
  74. { Extra mod sig. trimmed. -mod}
  75.  
  76.       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
  77.       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
  78.       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
  79.       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]
  80.